其他
【数据蒋堂】第25期：有序分组
我们知道，SQL延用了数学上的无序集合概念，所以SQL的分组并不关注过待分组集合中成员的次序。我们在前面讨论过的等值分组和非等值分组，也都没有关注过这个问题，分组规则都是建立在成员取值本身上。但如果我们要拓展SQL，以有序集合为考虑对象时，那就必须考虑成员次序对分组的影响了，而且，现实业务中有大量的有序分组应用场景。
一个简单的例子：将一个班的学生平均分成三份（假定人数能被3整除）。按我们在前面所说的分组定义，这也可以看成是一种分组，但这个运算在SQL中却很难写出来，因为分组依据和成员取值没有关系。
如果使用我们在前面讲有序遍历语法时的#符号，这个问题就很容易解决了。
A.group( (#-1)*3\A.len() ) // 按序号分成前1/3，中1/3，后1/3
A.group( (#-1)%3 ) // 还可以按序号每三个中取一个构成分组子集
用SQL实现这个运算就麻烦很多，需要先用子查询造出一个序号，然后再执行类似的分组规则。
上面这个例子中其实还没有真正关注成员的次序，只是说明了序号的作用，待分组集合的成员是其它次序时也可以得到可用的结果。
我们再看更多例子。
处理文本日志时，有些日志的基本单位不是1行，而可能是3行，即每个事件总是写出3行文本，这并不是多罕见的情况。对付这种日志时，就需要把文本每3行拆成一个分组子集，然后针对每个分组再进行详细的分析处理。这时要正确的分组运算就必须依赖于待分组集合中成员（文本日志的行）的次序了。
入学考试之后，把学生按成绩排序蛇行分拆成两个班，即名次1,4,5,8,...在一个，而2,3,6,7,...在另一个班，这样能保证两个班的平均名次是相同的。这个分组也可以用序号做出来：
A.sort@z(score).group(#%4<2)
这里用的分组值不再是常见的普通数值，而是一个布尔量，相当于按“真“值和“假”值分成两个组，真值对应第一个班，假值对应另一个班。本质上讲，这还是个等值分组，只是用到的分组值可以是任意泛型。
显然，这个分组的正确性也严重依赖于待分组集成的成员次序。
顺便说一句，这又是一个只关注分组子集而不关心聚合值的例子。
按序号分组在很多情况下就是用序号来计算出分组依据，然后就变成普通的等值分组了。那么有没有不能简单地转换成等值分组的情况呢？
2. 值变化分组
有一组婴儿出生记录，是按出生次序排序的，我们现在关心连续出生的同性别婴儿数量超过5的有多少批？
简单想，这就是先GROUP，计算每组COUNT值，然后数出有几个大于5的。后两步很简单，问题是怎么GROUP？
直接按婴儿性别分组当然是不对的，必须考虑次序，依次扫描记录，当婴儿性别发生变化时则产生一个新组。这种分组显然没法直接用等值分组做出来了。
我们可以提供一个有序分组方法来实现这种分组：当考察值发生变化时就产生一个新的分组。
A.group@o(gender).count(~.len()>5) // @o选项表示分组值变化时将产生新分组。
用SQL就麻烦很多，需要先造成中间标志和变量来生成组的序号，大概是这样
SELECT COUNT(*) FROM
(SELECT ChangeNumber FROM
(SELECT SUM(ChangeFlag) OVER (ORDER BY birthday) ChangeNumber FROM
(SELECT CASE WHEN gender=LAG(gender) OVER ( ORDER BY birthday) THEN 0 ELSE 1 END ChangeFlag FROM A))
GROUP ChangeNumber HAVING COUNT(*)>5)
这样的SQL，看懂都不是很容易的。而且必须借助birthday这种字段来形成次序，而前述的有序分组写法在原数据有序时根本用不着这个信息。
这种场景同样可能出现在文本分析中。每个用户的事件日志可能多行，而且行数不确定，但写日志时会在每个行开始处写上用户号。这样我们可以按这个用户号进行有序分组，它变化时就说明是另一个用户的事件了。
即使是普通的等值分组，如果事先知道原集合对分组字段有序，也可以使用这种方案来实施，这将获得更高的性能，比数据库常用的HASH分组方案要快得多，而且特别适合大数据遍历的情况。
3. 条件变化分组
再看一个著名的问题：一支股票最长连续上涨了多少天？
这个问题当然可以直接遍历去解决，不过我们现在用分组的思路来处理，至少在SQL体系下只能这么做（严格些说，这是目前找到的最简单可行的办法）。
将股票收盘价按日期排序，然后将连续上涨的日期分到同一组，这样只要考虑哪一组成员数最多即可。更明确地说，就是当某天上涨了，就把这一天和前一天分到一个组中，某天下跌了，则产生一个新组。
用SQL实现这个思路，同样需要用中间标志和变量来生成组序号：
SELECT MAX(ContinuousDays) FROM
(SELECT COUNT(*) ContinuousDays FROM
(SELECT SUM(RisingFlag) OVER (ORDER BY TradingDate ) NoRisingDays FROM
(SELECT TradingDate,
CASE WHEN ClosingPrice>LAG(ClosingPrice) OVER (ORDER BY TradingDate THEN 0 ELSE 1 END) RisingFlag
FROM A))
GROUP BY NoRisingDays)
如果有专门的有序分组方法以及以前说过的有序遍历语法，这个运算就很简单了：
A.sort(TradingDate).group@i(ClosingPrice<ClosingPrice[-1]).max(~.len()) //选项@i表示当条件成立时产生新分组
与SQL不同，虽然实现思路完全一样，但写出来是分步的，而不是一个多层嵌套语句，书写和理解都要容易得多。
同样地，这种场景也会在文本分析中有用。不确定行数的日志中，有时会在事件分始时写一个标志串，当扫描到这个标志串的时候就产生一个新的分组，有序分析的条件可设定为当前扫描行和指定文字相同，这样就能保证同一事件的日志信息在同一个组中。
后两种有序分组的情况，理论上当然也可以转换成等值分组来处理（用SQL就要这么做，这也能从另一个侧面说明SQL运算体系的完备性），但确实是相当麻烦的，所以我们一般不把它再当成等值分组来处理了。
到目前为止的分组讨论，都是假定待分组集合已经准备好，其成员可以被随机访问到。但如果数据量巨大而不能全部读入时，如果继续做这种假定，会导致频繁的外存交换而性能极差，这时需要再设计以流方式边读入边分组并且边聚合的运算体系。事实上日志分析中更常见的是这种情况，这些问题我们将再撰文研究，但基本方法思路仍然离不开上面这些内容。
正文结束
近期文章
《数据蒋堂》的作者蒋步星，从事信息系统建设和数据处理长达20多年的时间。他丰富的工程经验与深厚的理论功底相互融合、创新思想与传统观念的相互碰撞，虚拟与现实的相互交织，产生出了一篇篇的沥血之作。此连载的内容涉及从数据呈现、采集到加工计算再到存储以及挖掘等各个方面。大可观数据世界之远景、小可看技术疑难之细节。针对数据领域一些技术难点，站在研发人员的角度从浅入深，进行全方位、360度无死角深度剖析；对于一些业内观点，站在技术人员角度阐述自己的思考和理解。蒋步星还会对大数据的发展，站在业内专家角度给予预测和推断。静下心来认真研读你会发现，《数据蒋堂》的文章，有的会让用户避免重复前人走过的弯路，有的会让攻城狮面对扎心的难题茅塞顿开，有的会为初入行业的读者提供一把开启数据世界的钥匙，有的甚至会让业内专家大跌眼镜，产生思想交锋。
蒋步星，清华大学计算机硕士，著有《非线性报表模型原理》等
1989年中国国际奥林匹克数学竞赛团体冠军成员，个人金牌。
2000年创立润乾公司，首次在润乾报表中提出非线性报表模型，完美解决了中国式复杂报表制表难题，目前该模型已经成为报表行业的标准。
2008年开始研发不依赖关系型数据的计算引擎，历经多个版本后，于2014年集算器正式发布。有效地提高了复杂结构化大数据计算的开发速度和运算效率。
2016年荣获中国电子信息产业发展研究院评选的“2016年中国软件和信息服务业 • 十大领军人物”。
2017年创办数据领域技术讲堂《数据蒋堂》，专注数据、每周一期。
2017年获得中国大数据产业生态大会评选的“2017年度中国数据大工匠”